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Abstract. Business Process Model and Notation (BPMN) provides a 
standard for the design of business processes. It focuses on bridging the 
gap between the analysis and the technical perspectives, and aims to 
deliver process automation. The aim of this technical report is to com¬ 
plement this effort by transferring knowledge from the related field of 
data-centric workflows aiming to provide automated performance op¬ 
timization of the business process execution. Automated optimization 
lifts a burden from BPMN designers and increases workflow flexibility 
and resilience. As a key step towards this goal, the contribution of this 
work is to provide a methodology to map BPMNv2.0 models to anno¬ 
tated directed acyclic graphs, which emphasize the volume of the tokens 
exchanged and are amenable to existing automated optimization algo¬ 
rithms. In addition, concrete examples of mappings are given, while the 
optimization opportunities that are opened are explained, thus providing 
insights into the potential performance benefits and we discuss technical 
research issues. 


1 Introduction 

BPMN has become an international standard for designing workflows. In prin¬ 
ciple, the basic promise of BPMN is the same diagram prepared by a business 
analyst to be used for automating the execution of that process on a modern 
process engine. This however remains a vision that rarely happens in practice 
and the gap between the business and the technical perspectives remains m- 
As a result, the executable workflow of business processes is either manually de¬ 
signed in order to provide enterprize-specific configurations or derived by simple 
procedures using toolkits from established vendors (e.g., Bigazi, IBM, Oracle). 
Either way, any performance optimization responsibilities rest with experienced 
IT technicians. 

In this work, a different approach is advocated, according to which perfor¬ 
mance optimization is automated. First, this type of automation relieves consid¬ 
erable burden from workflow designers. Second, automated optimization yields 
intrinsically more flexible and resilient workflows. Flexibility and resilience are 
deemed as both key and particularly challenging aspects in modern BPM mm- 
Increased flexibility stems from the fact that several equivalent alternatives are 
investigated by the optimizer thus providing more options. Also, when external 




conditions that impact on the workflow performance evolve, automatically re¬ 
optimizing the workflow is important for efficiently adapting to the new setting 
to attain resilience. Third, performance issues are playing an increasingly im¬ 
portant role in modern BPM, which becomes more data- and process-intensive, 
e.g., in order to cope with big data [8] giving rise to the need for performance 
optimization. Finally, optimizers for automatically deriving execution details is 
an integral component in systems that aim to allow end users to submit the 
process definition at a higher level, e.g., as discussed in [El- 

Performance optimization is a field that has been largely investigated in 
databases (e.g., m) and data-centric flows (e.g., |23I19I10I16I13I1^ 1. Although 
these techniques cannot solve the problem of business process optimization in 
its entirety, they can form a starting for automated performance optimization, 
as explained in this work. The key first step is to bridge the modeling gap: 
data-centric flows are typically represented as directed acyclic graphs (DAGs) 
and optimization techniques rely on statistical metadata, such as cost per task 
invocation and selectivity, which can be regarded as annotations to these DAGs. 
We adopt the same modeling abstraction for business processes, and we explain 
how BPMNv2.0 elements are translated to such annotated DAGs. The intention 
is to keep using the BPMN standard and the mapping to a DAG, along with the 
subsequent optimizations, to occur automatically in a way transparent to the 
process designer. 

In summary, the maim contributions of this technical report is the introduc¬ 
tion of an annotated DAG-based approach to BPMNv2.0 modeling along with 
concrete examples of mappings of the main BPMNv2.0 elements. A smaller con¬ 
tribution is the presentation of the optimizations enabled with insights into the 
potential benefits in terms of performance; these optimizations are inspired by 
their counterparts in the data management area. For completeness, we briefly 
discuss the main technical research issues as well. 

In the remainder of this section, a motivating example and an overview of re¬ 
lated work is provided. Next, we elaborate on our DAG modeling abstraction. In 
Section[31 the mappings of the main BPMNv2.0 elements to the DAGs proposed 
hereby are provided. The optimization opportunities and the open research is¬ 
sues are discussed in Sections |4] and [5l respectively. Conclusions are in Section 

El 

1.1 Motivating Example 

As a motivating example, we use a sub-process that is encountered in banks for 
processing loan requests. Upon receiving a customer application, an employee fills 
in the applicants personal details, and then performs a series of tasks contacting 
trusted services from third parties on the web. Such tasks include the following: 
to import additional customer personal data, to check if the applicant is on any 
black list, to check the borrowing capacity and to check the information with the 
help of the national credit bureau. If any of these checks fails, the process aborts 
and the application is rejected. Finally, the third party services are invoked by 
providing the customer’s SSN identity number. 




This scenario is simple but capable of showing a set of optimization issues 
involved. We give some examples: Which is the optimal sequence to contact the 
third-party services in terms of performance, given that several orderings are 
valid (e.g., it does not matter whether the check of the borrowing capacity precedes 
the check regarding the black lists and vice versa)? Should the invocations be 
performed in parallel? Should an employee fill full personal details only after the 
checks have passed? In the envisaged approach, one can take these decisions 
automatically, in a principled manner in the sense that cost-based algorithms 
(which may well be accompanied by theoretical optimality guarantees) can be 
employed. Further discussion on this is deferred to Section |4l 


1.2 Related Work 

Automatically devising executable workflows that speed-up execution or improve 
on other performance metrics is an overlooked area in business process manage¬ 
ment (BPM). Optimization in BPM focuses mostly on meeting customer needs 
and adapting to changing market conditions mu- Performance optimization 
is considered in the context of process redesign, which covers several topics, as 
discussed in [7]. Some examples are to divide an existing process into two or 
more separated processes, to eliminate obsolete activities, to assign tasks to 
the more specialized person and, in general, to perform judicious responsibility 
assignment, and to buffer requests to external information sources. The most rel¬ 
evant heuristics to database-like optimization are the so-called “business process 
behavior heuristics”, which include re-sequencing, knock-out, and parallelism. 

Re-sequencing covers the optimizations that involve changing the execution 
order of activities, while preserving the process semantics and correctness. It is 
the form of optimization that the database community has been investigating 
since several decades, albeit making different assumptions. A specific form of re¬ 
sequencing is to move activities that check conditions, which if not met, lead to 
process termination, as early as possible. Such activities are termed as knock-out 
ones. This bears similarities to the filter ordering problem in database queries. 
Parallelism deals with decisions as to whether some activities should be executed 
in a sequential or a time-overlapping fashion. As with re-sequencing, similar 
decisions are also enabled by database optimizers. We target exactly these form 
of optimizations, but in a cost-based manner instead of using ad-hoc heuristics. 

Also, there are techniques that restrict their optimizations in the data man¬ 
agement tasks within business processes; for example, the proposal in |23) tries 
to consolidate tasks that access databases, thus yielding workflow transforma¬ 
tions with fewer and more complex underlying SQL statements, which overall 
lead to higher performance. The technique in [3] considers BPMN flows but is 
restricted to optimization of data analytics. Finally, business processes, similarly 
to scientific workflows, can be modelled as Petri-nets or described with the help 
of TT-calculus and other forms of logic [3] ; such approaches however are very dif¬ 
ficult to enable cost-based optimization m although they allow for other useful 
functionalities, such as querying as discussed in [6]. 



2 The proposed DAG-modeled abstraction 


In data-centric flows, which are also described as DAGs, each graph vertex corre¬ 
sponds to a task. The tasks manipulate data (e.g., extract sentiment information 
from tweets, combine user identifier numbers with customer info from an under¬ 
lying database, and so on), and the edges denote how the transformed data flow 
across the tasks. Since performance in these data-centric flows is directly depen¬ 
dent on the volume of data being processed and the capacity of the execution 
engines, the optimization methodologies aim to process as fewer data as possible 
and make judicious assignment of tasks to resources. For the former, the key 
idea is to prune unnecessary data, that is data that do not contribute to the 
flow final desired result, as early as possible. 

In business processes, the things that flow across tasks are “tokens”. So, our 
DAGs emphasize the volume of the tokens flowing rather than the business logic 
and the control of the flow. Each BPMN task corresponds to a vertex in the 
DAG. A directed edge connects each ordered pair of vertices, between which a 
transmission of tokens takes place in the context of the process. 

The goal of the performance optimization is to improve the average perfor¬ 
mance across multiple process execution. Performance can be crisply defined in 
several ways, some of which are discussed in Section|31 Statistical metadata drive 
the optimization procedure. This metadata are typically extracted from log files. 
The exact type of metadata depend on the specific optimization problem, but 
two types are most commonly encountered: selectivity and cost (per invocation). 
Selectivity is the average ratio of output to input tokens. For example, a task 
that, for each given recipe, triggers a task to prepare a single meal has selectivity 
1. If a task performs a check and may cause early process termination in case of 
the test failure, the selectivity is lower than one. Analogously, if a task produces 
multiple tokens per input token on average, its selectivity is above one. In all 
the cases, the output tokens flow across all outgoing edges of the corresponding 
vertex. The cost of a task is measured in the same units as the performance 
criterion. If performance is measured in time units, then the task cost is the 
average time needed to execute that task. In BPMN processes, things (captured 
by tasks) have to be done under certain circumstances (captured by gateways); 
in our DAG-based approach, the statistical metadata play an important role in 
considering the gateways semantics through annotations to vertices. 

Apart from the statistical metadata, there are two other categories of meta¬ 
data needed. The first category covers dependency constraints between task 
pairs, i.e., whether a task must precede another one in any execution plan to 
preserve semantic correctness or whether two tasks must be placed on distinct 
DAG branches, where each DAG branch corresponds to a different execution 
path. The second category captures behavioral characteristics, such as whether 
the task can be parallelized, so that its workload is executed by multiple execu¬ 
tors in parallel, and whether a task can operate in a pipelined manner, i.e., to 
be capable of producing output before consuming its entire input. 

A distinctive feature of our proposal is that BPMN tasks correspond to DAG 
vertices but the opposite does not necessarily hold. We employ the notion of 


artificial tasks termed as dummy tasks. Overall, the combination of normal and 
dummy tasks with appropriately set statistical metadata allow for modeling the 
token flow in business processes and paves the way for performance optimization, 
as discussed next. 

3 BPMNv2.0 Symbol Mapping 

In this section, we describe how we can model the main elements of BPMNv2.0 to 
our annotated DAGs. The examples are deliberately simply to convey easier our 
message, and they are drawn from the Camunda platformj^ To avoid confusion, 
the tasks in our DAGs are depicted as circles rather than rounded rectangles, 
following also the standard convention for vertices in graphs. 

3.1 Activities 

Task. An ordinary task, independently of its exact type (e.g., manual, service, 
business rule, and so on), is mapped to a distinct vertex in our model. The cost 
metadata is the average cost in time units to execute that task, and its selectivity 
is the average ratio between the output and input tokens. 

For example, in Figure [I] there is the task “prepare meal”. This task is 
triggered after it has received the menu suggestions from the previous task. If 
the average time to prepare a meal is c_pm, then the cost of that vertex takes 
that value. The selectivity is set to 1, because for each suggestion there is a single 
meal prepared. 

The loop tasks, like the “suggest dish” one in the figure, require a bit more 
attention, because they execute more than one time on average. Let us suppose 
that the average number of times the task is activated is n and the average time 
cost to execute each time is csd. There are two ways to handle this case. First, 
we can insert a zero cost dummy task before “suggest dish”. The selectivity of the 
dummy task is set to n, whereas the cost of the vertex corresponding to “suggest 

^ http://camunda.org/bpmn/reference/ 



set = 1 sel = 1 

cost = n X c_sd cost = c_pm 


Fig. 1. Mapping a loop and an ordinary task. 








sel = p2<l sel = 1 

cost = 0 ttost - c_ct 


Fig. 2. Mapping a compensation task. 


dish” remains csd. However, the selectivity of this vertex needs to become 1/n 
to account for the fact that even if n times the “suggest dish” task is executed, 
there is always one token passed on to the subsequent task. The second option is 
not to use a dummy task and amortize the cost of the vertex, so that it captures 
the fact that, on average, it is executed n times and thus becomes n x csd. 

Both options are shown in Figure [TJ The second one is simpler, but it hides 
the information about the average number of iterations. In cases where this is re¬ 
quired, e.g., to devise optimized plans or compute metrics that are parameterized 
according to n, then the first approach should be preferred. 

In the previous examples both tasks are not parallelizable. The multiple 
instance tasks can be modeled in the same way as the loop ones, but the difference 
is that they can be parallelized up to a parallelism degree of n. 


Compensation Tasks Compensation tasks can be mapped to our DAG with 
the help of dummy tasks as well. Consider the example in Figure[2l where a book 
trip task with cost c_6r is associated with a compensating task cancel trip with 
cost c-ct. Let as also assume that the probability of not triggering the compen¬ 
sating task and continuing the normal execution is pi, whereas the probability 
of canceling the trip is p2=l-pl. The mapping to our DAG involves two dummy 
tasks, which do not contribute to the cost, but control the amount of flow to 
each of the two branches in a way proportional to the afore-mentioned proba¬ 
bilities through setting their selectivities accordingly. The preceding task in this 
example sends its output to both branches in line with the edge interpretation 
in our DAG model, and it is the responsibility of the dummy tasks to perform 
the filtering. The dependency constraints state that none of the two initial tasks 
should precede the other, i.e., the optimizer cannot place them in a sequence. 

Note that a simpler mapping would also be possible in cases where the two 
branches merge just after the book and cancel tasks. In that mapping, we could 
omit the dummy tasks and have only the book trip task with selectivity set to 1 
and a weighted cost equal to pi x cJ>k + p2 x c-ct. This mapping does not cap¬ 
ture the complete business logic, but is adequate for performance optimization. 
Similarly, if there are subsequent tasks following book trip but no output edge 









Fig. 3. Mapping an ad-hoc task. 


for cancel trip, we could have a single task with the weighted cost as above and 
the selectivity being equal to pi. 

Subprocess. Subprocesses do not pose any specific challenge per se with re¬ 
gards to their mapping. However, for optimization purposes, it is always more 
desirable to expand them in order to broaden the optimization search space of the 
algorithms, provided that those algorithms are capable of navigating efficiently 
through the expanded search space. 

Call Activity. From the performance point of view, call activities can be treated 
like ordinary activities in the way described above. 


Adhoc. Adhoc subprocesses contain several tasks that can be executed at any 
order. This is exactly the sweet spot for database-like optimization, which can 
decide on the optimal order in a principled manner. In Figure [3l we present an 
example with an adhoc subprocess with 4 tasks that can be executed in arbitrary 
order. We map them in the way shown in the right part of the figure; all the 
tasks in the adhoc subprocess are directly connected to the preceding task to 
denote that there are no inter-dependencies among them and, as such, can be 
computed in parallel (although the final decision rests with the optimizer as 
discussed later). Also, we use a zero-cost dummy combiner task to aggregate the 
output tokens of the adhoc tasks and call the next activity. The selectivity of 
that dummy task is set to 0.25 because it outputs one token for every four tokens 
received as input. Further, it is not pipelining, because it needs to consume all 
its four input tokens in each execution, before creating an output token. 


Event Subprocess. An event subprocess may be executed while the enclosing 
subprocess is active. An example is presented in Figure HI where the enclosing 
process is a task prepare meal, during which new guests can be included (cap¬ 
tured by the event task include guest). The costs of these tasks are C-pm and 
C-ig, respectively. To map this case to our token-flow DAG, we insert a dummy 
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Fig. 4. Mapping an event subprocess. 



Fig. 5. Mapping an exclusive gateway. 


filtering vertex with selectivity equal to the probability of executing the event 
subprocess pi. Note that, by definition, c-ig is always less than c-pm, and the 
two activities cannot be executed sequentially. 


3.2 Gateways 

Exclusive, Parallel and Inclusive. Gateways is a core BPMNv2.0 element 
and a distinctive feature of process-centric flows not appearing in data-centric 
workflows. As such, their effective mapping is of high significance in our ap¬ 
proach. We distinguish between exclusive, parallel and inclusive gateways. An 
example of an exclusive gateway is in Figure [51 where there is an option during 
meal preparation for the three dishes shown. Let us assume that the average 
probability to select each of the three options is pi, p2, and p3, respectively; 
these probabilities need to sum to 1 to account for the fact that always exactly 
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Fig. 6. Mapping a more complex exclusive gateway. 


one option is selected. Then, we can insert zero cost dummy filtering tasks with 
their selectivity set equal to the probabilities above. There is also a zero-cost 
unary-selectivity dummy combiner task being responsible for synchronization, 
but this is optional. To preserve the gateway semantics, the dependencies be¬ 
tween these vertices are that they cannot be placed in a sequence. 

Now, suppose that, in the previous example, the gateway is transformed to a 
parallel one. Then the dummy tasks on the left become optional (corresponding 
to zero cost and selectivity equal to 1), so that the three previous options can 
be directly connected to choose recipe. However, the dummy task on the right 
becomes compulsory and its selectivity is set to 1/3, derived by a generic formula: 
ratio of 1 to the number of tasks after the parallel gateway. This is to ensure 
that eat meal receives a single token for each choose recipe execution no matter 
how many intermediate tasks are executed in parallel. In addition, the dummy 
task on the right enforces synchronization. 

Inclusive gateways allow tokens to flow across one, many or all paths, i.e., 
the combine certain features from the exclusive and parallel cases. The high- 
level mapping shown in Figure [5] holds for inclusive gateways as well, but with 
all dummy tasks being compulsory. Contrary to the case of exclusive gateways, 
the selectivities of the dummy tasks preceding the options can sum to a value 
greater than 1. In addition, the dummy combiner task on the right part becomes 
compulsory (as in parallel gateways) and its selectivity is set to the ratio of I to 
the sum of the selectivities on the left. 


Gateways and Loops. Gateways are very common to be accompanied by 
cycles in business graph models, as shown at the top of Figure[6l We can combine 
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Fig. 7. Mapping a subprocess with a boundary event. 


the approaches presented earlier regarding loops and gateways in order to render 
our graph acyclic. The tasks belonging to the loop path are placed in a sequence 
with their cost having been amortized as shown in Figure [T] the alternative of 
a dummy task in that figure is also valid. Then, the rest of the tasks after the 
gateway are treated as in Figure El 

Event-based vs. Data-based Gateways In BPMNv2.0, there is a distinction 
between data-based and event-based gateways. The former choose the routing 
of a token to one or more paths according to data associated with the specific 
token. The latter make decisions based on events happening. From the perfor¬ 
mance point of view, there is no essential difference between these two cases. 
For example, consider the exclusive case. Instead of monitoring the probabili¬ 
ties of task activation, in an event-based exclusive gateway, we can monitor the 
probability of corresponding events and set the selectivities in our DAG vertices 
accordingly. Next, we discuss BPMNv2.0 events in detail. 

3.3 Events 

In general, events impact on the task statistical metadata from the time perfor¬ 
mance perspective. Not all events need to be mapped to our DAG though. For 
example, process starting need not be explicitly defined, since we are interested 
in modeling and optimizing the average performance of process execution rather 
than on enacting the processes. 


Boundary Events. Boundary events are intermediate events that may cause 
interruption of task execution. Consider the example in Figured Taskl starts its 
execution and, at some while it is still active, it may be interrupted if a boundary 
event occurs. The interruptions causes immediate termination of taskl and the 
token is passed to task2. If no event happens, taskl is completed normally and 
the token is passed to its next task. 

Let us suppose that the costs (resp. selectivities) of the two tasks are C-tl and 
C-t2 (resp. seLtl and seLt2). Also, the probability of taskl executing normally 
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Fig. 8. Three cases of using timer events in BPMNv2.0. 


is pi and the probability of an event is p2=l-pl. In our DAG, we create two 
branches to denote each execution mode. At the beginning of each branch, we 
place a dummy filtering task with the selectivity equal to the probability of 
following the corresponding path. There is one more subtle detail. When taskl 
is interrupted, it has already incurred some cost, which needs to be captured. 
Let us suppose that, on average, when the interruption takes place, this is after 
cost time units; this quantity becomes the cost metadata for the dummy vertex 
of the event-related branch. 

BPMNv2.0 also accounts for non-interrupting boundary events. In the pre¬ 
vious example, if the event was non-interrupting, the execution of taskl would 
always complete. In that case, the difference in the mapping will be that the 
dummy activity on the normal path is placed after the task. The rest remains 
the same. 


Message. Messages play an important role in BPM but are not related to 
performance. As such, they can be omitted. In case we want to capture them 
explicitly, e.g., as if they play a checkpointing role, we can insert corresponding 
dummy vertices with zero cost and unary selectivity. 


Timer. Timer events are important for performance in time units, and need to 
be handled with care according to their semantics. We examine three representa¬ 
tive cases of timer event usage, as shown in FigurelH In the first case, we execute 
a subprocess and the second subprocess starts its execution at Sam. From the 















performance optimization point of view, this event inserts a time barrier and 
implies that the two subprocesses need to be optimized for performance inde¬ 
pendently. That is, we need to create two DAGs, one for the subprocess before 
the timer event, and one for the subprocess after it. 

The second case is different and refers to a time break of 10 minutes. In that 
case, we insert a dummy task with unary selectivity and time cost equal to the 
amount of time units, which is equivalent to 10 minutes. Third, time events can 
play the role of boundary events considered above. One important difference 
however is that, if these events are interrupting, the time cost of taskl should 
not be its average cost in time units, but the average cost when the event is not 
triggered. Analogously, the cost of the dummy activity on the event path should 
be equal to the amount of time passed in order to trigger the event. 


Error and Compensation. In general, errors may not be considered, given 
that performance optimization makes more sense when everything is executed 
correctly. For the specihc cases where errors trigger subprocesses and compen¬ 
sation tasks, the methodologies described above apply. The same holds for the 
compensation events, too. 


Conditional. Conditional events may postpone the token propagation to the 
subsequent tasks until a set of conditions is satisfied. This affects the time perfor¬ 
mance, and to capture the impact we need to insert a dummy vertex at the place 
of the conditional event with cost proportional to the amount of time waiting 
in order to meet the requirements. In general, the selectivity is set to 1; if there 
are execution examples, where the conditions are never met so that the events 
acts also as a filter, then the selectivity is configured accordingly. 


Signal. Signal events have no differences with messages from the performance 
point of view. 


Termination. This type of events affects the amortized cost of all processes 
that may be terminated. For example, if a task has cost cl in pl% of the cases, 
and in the rest, it is terminated due to a terminate event after c2 time units, its 
amortized cost becomes pi x cl -|- (I — pi) x c2. 


Cancel. Cancel events affect the selectivity of subsequent transaction processes. 


Other Event Types. BPMNv2.0 provides for further event types, which how¬ 
ever, do not require special treatment. Such types include the links, multiple and 
parallel, and escalation. Multiple and parallel provides insights into how often a 
complete subprocess is triggered, thus possibly affecting the selectivities of ordi¬ 
nary and dummy tasks. Finally, the behavior of escalation from the performance 
point of view is covered by elements such as gateways. 




Fig. 9. Example benefits when optimally reordering activities. 


4 Optimization Opportunities 

The optimizer envisaged, can take the initial mapping, and the set of statistical 
and dependency metadata and derive an optimal execution plan. Two main 
optimization approaches are to decide the exact order of task execution and 
the assignment of tasks to executors (either engines or humans) in a cost-based 
manner. 

To provide insights into the benefits, we extend the motivating example, 
where the ordering of some tasks is flexible thus generalizing adhoc tasks in 
BPMN. Suppose a simple process, which contains n activities forming a chain 
(i.e., there are no branches). If, due to dependency constraints, there is no flex¬ 
ibility in the order, then this implies that there are dependency edges, 

either explicitly stated or implied through transitive closure; e.g., if task A must 
precede B, which must precede C, then it is inferred that A must also precede 
C. In practice, this rarely happens. For example, a loan pre-processing template 
may define the order in which the tasks for importing contact information of 
the applicant, checking the borrowing capacity and contacting the credit bureau 
take place, despite the fact that any ordering is valid. 

Figure ini shows the performance improvements over 100 randomly generated 
DAGs, where there are 0.75 "^”~^^ and 0.5dependency edges, n ranges 
from 10 to 15, the selectivity of tasks ranges from 0.01 (extremely filtering) to 
2, and the cost ranges from 1 to 100 (i.e., the cost of the most expensive task is 
two orders of magnitude higher than the cost of the less expensive one). In all 
DAGs, the exact values were randomly chosen with uniform distribution. The 
exact optimization metric selected is the sum the average execution time for each 
task; the latter is defined as the product of the task cost and selectivity values of 
the preceding tasks. This optimization metric defines the average running time of 
the process. As baseline performance, which corresponds to normalized value 1, 
















we consider the running time of the initial DAG before re-orderings. In the figure, 
we can see that, on average, there is a reduction in the running time by 25.62% 
for the more constrained case; moreover, the average reduction becomes 40.37%, 
for 50% constraints. Also, there are isolated runs, where the improvements can 
be of several factors (up to an order of magnitude), as shown by the maximum 
improvement plots at the bottom of the figure. These numbers indicate how 
significant the performance benefits can be, even in simple processes. 

Of course, exploring all the orderings, even in highly constrained settings, 
is an intractable problem. The techniques in m show how the optimizer can 
navigate through the search space in a scalable manner. Other performance 
optimization problems can be considered as well. For example, the technique in 
[20] is applicable to a variant of the previous setting, where all tasks are executed 
in parallel and some of these tasks are acting as performance bottlenecks, e.g., 
because they are manual ones; in that case, the optimization goal is to order 
the tasks in such a way, so that the average bottleneck is mitigated as much 
as possible. A nice feature of this technique is that it automatically decides 
whether a task should be executed in parallel with others or not. Another flavor of 
performance problems is to minimize the sum of the task costs across the critical 
execution path of the business process DAG rather than considering the complete 
process, leveraging the techniques in [I]. As a final example of optimization 
goals enabled by task re-ordering, presents techniques that maximize the 
throughput (i.e., equivalent to token consumption rate) through maximizing the 
utilization of each executor. 

In addition and again with a view to improving performance, task assignment 
can be performed in a principled manner. As an example, we mention the ap¬ 
proach in [14] , where the different execution options for each task are checked in 
a scalable way, while taking into account realistic aspects, such as the overhead 
when switching between executors (e.g., two adjacent manual tasks are delegated 
to different persons) and that each task can be executed only by a restricted set 
of executors (e.g., a manual task cannot be performed by any employee). 


5 Main Research Issues 

Here, we mention the main research issues for developing complete solutions for 
performance optimization in BPMN business processes. 

— Need for dependency-aware optimization algorithms. Mapping BPMN mod¬ 
els to our DAG abstraction is a necessary but not sufficient condition to 
perform cost-based performance optimization. In the previous section, we 
referred to several algorithmic techniques; albeit those techniques cannot ap¬ 
ply to generic DAGs produced by the proposed mapping from BPMN. The 
reason is that, those algorithms consider only precedence constraints, i.e., 
constraints of the form that task A must precede task B. This type of con¬ 
straints needs to be complemented by (i) parallelism constraints that enforce 
tasks to be placed in different execution paths; (ii) blocking vs. pipelining 


information for each task; and (iii) parallelism capability information, to de¬ 
fine which tasks are amenable to parallel execution and up to which degree 
of parallelism. Consequently, more research is needed in optimization algo¬ 
rithms to develop solutions that account for the complete range of constraints 
in business processes. 

— Statistical Metadata Collection. The statistical metadata play a crucial role, 
and their efficient collection requires special attention. Techniques like the 
one in and histograms m may act as a starting point. Challenges include 
the fact that statistics are actually correlated, which means that changing 
the order of tasks may affect their statistical metadata. For example, a timer 
boundary event may fire less frequently, if the optimizer assigns the corre¬ 
sponding task to a more powerful execution engine, so that it takes less time 
to complete on average. This again relates to the need for more advanced 
optimization algorithms that can handle such correlations of statistical val¬ 
ues. 

— Extensive Evaluation. There needs to be extensive evaluation using bench¬ 
marks to reason with confidence about the actual capability of each proposed 
optimization technique. TPCi has developed such benchmarks for database 
queries but no related efforts for business processes exist to date. 

— Mapping to BPMN models and end-to-end solutions. In this work, we showed 
how we can map BPMN models to our DAGs and perform optimizations 
under a specific case of dependency constraints. Holistic solutions should 
involve the mapping of the optimized execution plan back to a BPMN model. 
In general, there is a need for end-to-end solutions that ideally would be 
exposed as a software plugin to existing platforms and encapsulate all the 
mapping and optimization methodologies in order to render the optimization 
fully transparent to the process designer. 

Finally, it should be remarked that, in BPM, optimization for performance 
only is inadequate; after addressing the issues above, the focus should also be 
shifted to aspects such as fault-tolerance [TH], reliability, economic cost and so 
on, potentially building on top of multi-objective query optimization fT71^ . 
This needs also to be complemented by theoretical investigation, since there is 
no theory of declarative business process optimization that is comparable to the 
one in databases [5]. 

6 Conclusions 

This work is motivated by the fact that currently, performance optimization of 
business process is a manual activity in the responsibility of the designer. Due to 
the complexity of modern processes and/or the volatility of the execution envi¬ 
ronment, there is no performance optimality guarantee. To address this limita¬ 
tion, automated performance optimizations should be applied. We explain how 

^ http://www.tpc.org/ 





we can build upon the knowledge in the data management community to opti¬ 
mize data-intensive queries and flows. More specifically, we discuss the annotated 
DAG modeling abstraction required to employ such solutions, going through the 
handling of the main BPMNv2.0 elements in detail. Using a concrete example, 
we provided insights into the potential performance benefits, which can be of an 
order of magnitude. Finally, we identified the main research issues for enabling 
automated optimization in BPM. 
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